Interfacing between ROSE and TCP/IP 


y 
Thomas A. Moulton, W2VY 
Radio Amateur Telecommunications Society 


INTRODUCTION 


The goal of the RATS Open System 
Environment (ROSE) X.25 Packet Switch 
from the beginning was to develop a radio 
network based upon standard protocols. It 
was also required that it provide reliable and 
completely transparent communications to 
all users of the AX.25 protocol. 


For over a year now ROSE has 
properly supported passing AX.25 frames of 
any protocol type (PID). This was just the 
first step taken by ROSE in providing fully 
transparent services to TCP/IP users. 


LEVEL OF SUPPORT 


For our purposes we define support 
to mean that communications through each 
other is completely transparent. We should 
strive to provide services for the normal 
modes of communication. There also may 
be points where some additional information 
could be displayed to help give third parties 
insight into the type of connection and/or 
source and destination. It should be noted 
that features used to provide support, in 
many cases, are general features, not special 
features added to make a specific 
configuration work. 


ROSE SUPPORT OF TCP/IP 


In order for ROSE to support 
TCP/IP it must pass IP frames transparently. 
This can only be evaluated at the end points 
of a ROSE connection, as ROSE is only 
required to reassemble the original frame 
that was sent into the network. 


VC Mode Connections 


ROSE currently only supports IP 
connections in VC mode and provides two 
classes of service, unreliable and reliable 
mode. The only difference in these two 
modes is the action that is taken when data 
might have been lost. In reliable mode the 
connection is simply cleared. In unreliable 
mode all the data queued within the network 
is discarded and a *** Call Reset *** 
message is sent and then normal data 
transfer is resumed. The message is sent 
with PID=FO which would cause NOS to 
divert the connection to the BBS interface, 
ROSE will only sent this message if the 
normal data also has PID=FO. 


When using unreliable mode the 
ROSE Switch generates two informational 
messages Call being Setup followed by a 
Call Completed or *** Call Clearing *** 
which are sent with PID=FO, this also causes 
the connection to be diverted to the BBS 
interface, even though: NOS is in the process 
of establishing this connection. These 
messages are sent before any user data has 
been sent, so the ROSE switch doesn’t know 
what the PID of the data will be. 


The net result is that NOS users are 
restricted to using ROSE reliable mode and 
NOS VC mode. One problem exists in this 
configuration, if the ROSE network detects 
a situation where data might have been lost 
it will tear down the connection, which will 
need to be restarted manually, since in NOS 
the VC mode handler does not attempt to 
reestablish a VC connection that fails. 
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Datagram Mode Connections 


In the future ROSE will support 
datagram service, where UI frames will be 
forwarded through the network based upon 
the network address in the digipeater field. 
This will also allow for ARP broadcasts to 
specific ROSE user ports if the digipeater 
path can be changed on the fly. This is not a 
severe limitation, as there will be specific 
RF channels that have concentrations of 
TCP/IP users. 


This will be a general feature 
independent of the actual PID in the UI 
frame. ROSE will manage an internal virtual 
circuit and maintain an idle timer that will 
keep a circuit open only while it is being 
used. This will reduce the number of X.25 
Call establishments that will be required to 
pass the data. 


TCP/IP SUPPORT OF ROSE 


A ROSE switch must be able to 
establish an inter-switch AX.25 connection 
through a collection of NOS nodes. What is 
needed is an AXIP type of feature that is 
initiated by specifying a single digipeater 
field. Presently the AXIP feature is activated 
by digipeating through the NOS callsign 
followed by an alias that indicates the 
network address that the frames will be 
forwarded to. This is similar to the method 
ROSE uses to establish connections. 


An additional extension to the AXIP 
feature would be to have the AX.25 Level 2 
locally significant. This would not effect the 
actions of ROSE, but it would reduce the IP 
traffic, since the idle RR’s would not be sent 
through the IP network. Then the only thing 
that would generate IP traffic would be an 
X.25 packet. 


ADDITIONAL FEATURES 


It would also be desirable for each 
environment to become aware of the 


existence of the other. The ROSE Switch 
USERS application will display the message 
"TCP/IP User” instead of "AX25L2 User” 
for the entry and exit points of a connection 
through the network. It would also be useful 
if NOS would capture and display the ROSE 
network address for connections terminating 
at a NOS node. NOS should keep track of 
any of the PID=FO messages, which indicate 
Reset or Clearing cause code. These could 
be used to trouble shoot network problems. 


TNOS - Tampa NOS 


There is work being done by Brian 
Lantz, KO4KS on a more ROSE aware 
version of NOS. Tampa NOS (TNOS) 
eliminates most of the problems discussed. 
This version has changes in the following 
areas: 


¢ Ignores PID=FO in VC mode 
connects 

Clean up for Dynamic Routing 
Specific IP Only Callsign 

Specific AX.25 Only Callsign 
Conference users list included each 
station’s ROSE Address 


With these changes the operation of 
TCP/IP is very predictable and will allow 
NOS users to use either reliable or 
unreliable mode ROSE connections. 


CONCLUSION 


If we all take a little time to make 
some simple changes in our software it can 
make the operation much simpler for all the 
users of our systems. It is not simply a 
matter of implementing the features needed 
to support every other system out there, but 
one of examining the general features 
needed to address the needs of many 
systems. I would like to thank Brian Lantz, 
KO4KS for his efforts in making TNOS. 
RATS will have the latest version available 
to those who want it. 


